1. Technical Field
The present invention relates to a multitask control method for processing a plurality of requests in parallel, and particularly to a method for supporting the construction of a multithread program.
2. Prior Art
Conventionally, to process a plurality of requests in parallel, a plurality of threads is created in a memory area managed by the system and a program is executed on a thread basis. The thread is the smallest execution unit existing in a process and characterized by a stack and a program counter. In an ordinary program, only one such execution unit exists, but, in a multithread program, a plurality of such execution units exists at the same time. That is, the concurrent execution of a plurality of processes is enabled, and it is an essential technique for developing server programs and the like.
However, in the prior art, as the functions of a server, the programmer needs to explicitly specify a facility for concurrently accepting client requests, and low-level instructions (API) for carrying out a processing for creating/deleting a thread, a synchronous processing among threads, and the like. Thus, the programmer is required to have a very high skill.
For instance, in the process for manipulating thread-specific data and global data, it is necessary to perform a programming shown below. In this case, it is exemplified by C++ (API of OS/2: xe2x80x9cOS/2xe2x80x9d is a trademark of IBM Corporation), which is one of programming languages. In this process, the Increment ( ) method of an Order object is invoked to increment a, a thread-specific variable, and simultaneously the result is stored in stock, a global object.
Thus, in the conventional multithread server programming, the programmer had to manage all by himself the contention among threads and the timing of deleting an object. This led to the risk of causing waste of memory due to program errors or data mismatch due to the contention among threads. These factors could cause the system reliability and throughput to degrade, or cause the server system to halt at worst. In particular, if a programmer at a relatively low skill level develops a server application, it is an important problem to provide a high degree of isolation to threads so that the respective processings do not interfere with each other.
Further, since the programmer must always be careful not to cause such problems, he must spend sufficient time in test and debug, which causes a problem of reduction in the productivity of programs.
Furthermore, in developing a typical multithread program in which requests are received from a plurality of clients and processed in parallel, there is a problem that the individual processings may interfere with each other. That is, the interference may produce a wrong result even though the individual processings are correct. To avoid such problem and develop a safe program, it is necessary to separately process the requests of clients and prevent the individual processings from interfering with each other as much as possible. Such technique for easily achieving the isolation of the individual processings is desired.
In connection with such prior art problems, Published Unexamined Patent Application Nos. 4-204656 and 4-195228 disclose a technique for declaring thread-specific data in the same fashion as global variables by analyzing a program in which a plurality of threads exists, and holding a specific data area start address for each thread during the execution of the program. However, even in such technique, since the programmer had to manage all by himself the contention among threads and the timing of deleting an object, the waste of memory due to program errors and the data mismatch due to the contention among threads could not be avoided.
On the other hand, in the conventional multithread control method such as Published Unexamined Patent Application No. 4-321136, once a thread is created, a certain memory region is allocated, but, even if the CPU execution right is not provided, the memory region is maintained until the program ends, and thus resources are not effectively used.
It is an object of the present invention to obviate the necessity of giving low-level instructions when describing a multithread program capable of concurrently processing the requests from clients, and provide the programmer with an environment in which he can create a multithread program without requiring high skill, thereby to increase the productivity of programming.
It is a further object of the present invention to avoid the waste of memory due to program errors and the data mismatch due to the contention among threads, thereby to increase the system reliability and throughput.
It is still a further object of the present invention If to provide a multithread control method in which resources are effectively used.
To solve these problems, an object to be referenced only from a single thread (referred to as thread object) is introduced, and to hide multithread-specific low-level processings (e.g. management of threads, exclusive control, synchronization, etc.), they are provided in the form of component. With the thread object proposed in the present invention, a safe program having a high degree of thread isolation can easily be constructed. Further, in the multithread programming, it is deemed that thread management, protection of shared resources using semaphore or the like, synchronization among threads, and the like are difficult. In the present invention, by providing such multithread-specific low-level processings in the form of component, the program development can be eased.
Although the thread object is effective in writing a safe program, there may be a case in which data must be shared among threads. In the present invention, considering such point, another type of object called shared object is provided. Being different from the thread object, the shared object can be accessed from a plurality of threads, and methods such as lock/unlock are provided in the viewpoint of protecting shared resources.
Moreover, in the present invention, the thread object and shared object are implemented by a lock object reference table and a global object reference table to ease the description of dedicated and shared resources. And, the user chooses whether the thread object or shared object is to be created. In the preferred embodiment of the present invention, the thread object and shared object are expressed by visualized program components, and by selecting them, either the shared object or the thread object is specified.
Before processing the client requests in the server, a thread/thread object control unit registrations the thread objects and shared objects specified by design into the global object reference table. Into the global object reference table, both thread and shared objects are registered. Stored in the table are the name of an object, the pointer to the object, and a flag indicating whether it is a thread object. In the global object reference table, as the entry of a shared object, the pointer to the actual object to be used is stored. On the other hand, the entry of a thread object becomes a template which is copied and used when client requests are processed.